Description

When an endpoint receives a new stream indication, it can provide some receive buffers inline to convert the stream to app-owned buffer mode.
When doing so, the receive buffer struct of the stream is reinitialized, and the virtual buffer length (which correspond to the stream receive window) was set to zero.

This is incorrect since we introduced the "more buffer needed" notification and the receive window is no longer tied to the amount of buffer provided.

This would result in a receive failure with data received outside of the virtual size.

When converting the receive buffer to app-buffer mode, the virtual size is now preserved.

Fixes #5672.

Testing

Test didn't catch this issue because the amount of buffer provided were too big and a single datagram would not allow to go over the virtual size.

Adding more test case:

• test all sender / receiver configurations
• test with various buffers numbers and sizes

While this is a large churn of test code to implement the various scenarios, the tested logic is still the same:

• provide some amount of receive buffer
• send data
• provide more receive buffers after some amount of data is received, or upon a buffer needed notification
• validate all the data is received correctly

Documentation

Clarify documentation about the app provided receive buffer ownership.